In current communication networks, mobile and fixed, operators face an increasing amount of “over the top” (OTT) content, which is to say, audio, video, or other content or applications that are delivered over an alternative to an operator's main delivery infrastructure. Thus, operators and network providers are increasingly reduced to simple bit pipes for data-intensive content providers such as YouTube, LLC, and other streaming-media providers.
For example, in December 2009, Amazon.com, Inc., announced a CloudFront web service for content delivery that uses Flash streaming and a real time messaging protocol (RTMP) from Adobe Systems Inc., making streaming easy to use even by unskilled users and further increasing OTT traffic in networks. Information about the CloudFront service is available at http://aws.amazon.com/about-aws/whats-new/2009/12/15/announcing-cloudfront-streaming/. The RTMP is described in Real Time Messaging Protocol Chunk Stream (June 2009), which is available at http://www.adobe.com/devnet/rtmp/pdf/rtmp_specification_1.0.pdf.
Much OTT content is redundant in the sense that, in many cases, the OTT content represents the same information or even the same media, just provided by different services and providers according to different communication protocols.
A web browser running on a client device is commonly used to access information on a server, or host, computer through the internet, and a browser typically acts as a hypertext transfer protocol (HTTP) client. Although the browser is a common application, browsers run nowadays on many different devices and platforms. Mobile phones, netbook, tablet, laptop and personal computers, television sets (TVs), set-top boxes (STBs), and even kitchen appliances are examples of client devices, or user equipments (UEs), that can have web browsers.
Current browsers identify information resources by uniform resource locators (URLs), and a current URL identifies one respective representation of information—in the best case, exactly that representation that is suitable for the device running the browser. A URL contains or encodes everything needed for delivery of the respective information: source, asset, transport, and possibly delivery parameters, which may facilitate charging for the delivery. URLs were originally specified by Request for Comments (RFC) 1738 (December 1994) by the Internet Engineering Task Force (IETF), and have been generalized and updated to uniform resource identifiers (URIs) as specified by IETF RFC 3986 (January 2005). A URI can be a locator, a name, or both, and a URL refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”).
It is possible for any information resource to be identified by a respective URL and accessed via messaging according to a suitable protocol. A user's client software application (e.g., a browser) reads the URL as an input parameter either directly from the user input or from a hyperlink, and the client application then downloads the resource identified by the URL and displays the content to the user, if it is able to do so. In general, the syntax of a URL can be described as follows:                <protocol>://<host>:<port>/<path>in which <protocol> indicates the type of messaging (e.g., HTTP, file transfer protocol (FTP), real time streaming protocol (RTSP), etc.), <host> is typically an internet address of the information, <port> is typically the number of a port used by the host for communication via the <protocol>, and <path> is a host operating system location of the information. The RTSP is specified by IETF RFC 2326 (April 1998).        
Since hosts can delete or move information, URLs can lose their validity, and so the HTTP defines a structure of error messages for invalid URLs. The error messages can state either that the resource is not available anymore or that it is now available through a new URL. The latter error message is called an HTTP redirect message, and the redirect can be either static or temporary. Modern client applications are able to interpret HTTP redirect messages and get the resources from the new URLs using HTTP. More and more clients support redirect messages that change the transport protocol. Also, resource identification and redirection is sometimes used for delivery of adapted hypertext markup language (HTML) information (e.g., web pages), in particular for delivery to mobile devices, for example.
Currently, there exist different approaches to separating semantic assets and actual representations of those assets. For example, the Persistent URL (PURL) project maintains a database of addresses that act as permanent identifiers despite Web infrastructure changes. Instead of resolving directly to Web resources, PURLs provide a level of indirection that allows the underlying Web addresses (e.g., URLs and URIs) of resources to change over time without negatively affecting systems that depend on them. This capability provides continuity of references to network resources that may migrate from machine to machine for business, social or technical reasons. Information about the PURL project is available at http://purl.ocic.org/docs/index.html.
Existing approaches to separating semantic assets and actual representations of those assets assume that each representation has a respective URL, which might change over time. Thus, a new URL must be defined for each different coding (or representation) of, say, a media program (or asset). That one-to-one requirement leads to several problems.
A single asset, such as a document, photograph, audio file, movie, etc., can be available in many different formats (representations), with a different URL for each format, but a typical user is just interested in accessing the asset itself, not in any particular one of its many possible representations. Simply presenting a list of hyperlinks to the user, from which the user must choose, results in a loss of operator and provider control over valuable good “bandwidth” because the user is either unaware of or does not consider the operator's or provider's needs. A simple list also reduces usability because a typical user will not understand the differences between the different formats and transport mechanisms represented by the listed different URLs. Moreover, the same asset may be available at several locations, such as content delivery networks (CDNs), streaming services, etc., but a URL known by a user might not be the representation of the asset that is suitable in terms of content location, network bandwidth, and user location. In addition, the same asset can be available through several transport protocols, such as HTTP, FTP, etc., but a URL known by a user might not be suitable for the transport capabilities of the user's device.
Because a URL directly addresses one respective representation of an asset, the representation is delivered to a user either directly or through one or more redirects, which are static, and so no additional information about the delivery context can be taken into consideration to improve the delivery. The static nature of current technology lacks the ability to adapt the reference of a URL at delivery time.
For RTSP-based delivery setups, the session description protocol (SDP) and real time control protocol (RTCP) could be used to negotiate delivery parameters via session invitation protocol (SIP) messaging. The SDP, RTCP, and SIP are specified by IETF RFC 3556 (July 2003), RFC 3605 (October 2003), and RFC 3261 (June 2002), respectively. The SIP is a mechanism for finding endpoints and routing control signals between them and is a set of simple operations, including REGISTER, INVITE, ACK, and BYE. SDP is a protocol for declaring media.
For example, as described in WO 2010/018421 A1 by Magnus Svensson et al. for “Extended Television Reminders”, the Internet Protocol Multimedia Subsystem (IMS) in cellular communication networks specified by the Third Generation Partnership Project (3GPP) uses the SIP and the SDP as its basic signaling mechanisms, and media transport is based on the RTSP, among others. Section 5 of 3GPP Technical Specification (TS) 24.229 V7.11.0, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Release 7 (March 2008) specifies SIP usage at a UE, and Section 6 of 3GPP TS 24.229 specifies SDP usage.
Nevertheless, an RTSP-based delivery is not transparent to the client, which means the user must interact in a complex, unfamiliar, way with the user's device, and is not available for HTTP-based delivery.
Providers like YouTube are already providing assets in different formats to users and choosing automatically which streaming format to use, but providers are not currently able to change the chosen streaming protocol. The choice of which stream to deliver is made based on available information on the server and client, but not on information on the delivery network itself. Thus, the choice misses important aspects for the network operator delivering the bits, such as transport cost.
Existing solutions are usually bound to a specific kind of resource, e.g., a movie clip. For each other resource type, the solution has to be adapted. Additionally, due to the proprietary single-client/single-server architecture of most solutions, existing solutions cannot be extended easily to consider more relevant information.